1. Technical Field
The present invention relates generally to isolating errors in a software runtime environment, and more particularly, to a system and method for dumping exceptions during execution of a computer program in an interpreted language environment.
2. Related Art
Identifying runtime problems in a software program can be a very time consuming and expensive process given the often inherent complexity of software. Difficulties arise because problems are often hard to identify and are not always evident when a program is executing. Such problems result not only in a costly process of isolating errors, but also result in low performance when such errors are unexpected or go undetected.
In many environments, runtime errors result in an “exception,” which can be dealt with during runtime to allow the program to continue executing. In a Java environment, for instance, when a runtime error occurs, the program can “throw an exception,” and a handler can be provided to “catch” the exception and deal with it. If a handler is not provided, the program will terminate and output some type of error message.
Problems often occur, however, because many applications write code that catch exceptions that perform some type of default behavior. In Java, for example, exceptions are sometimes caught generically, such as with the statement:
catch (Exception e) {/* do nothing */}.
In this case, nothing is done except to consume the exception. While this may work fine for cases where the exceptions are intended, it may be insufficient to handle other, perhaps unintended, exceptions such as a ClassNotFoundException. In cases where the exception is due to some user error (e.g., configuration problem, missing classpath item, etc.), the program will behave badly, and there may be no visible sign of what the problem is.
In addition, many times applications use exceptions to pass back errors or event notifications (e.g., correct responses). The use of exceptions in this manner can be a performance overhead, particularly in a system where there is a large stack depth. In such cases, the creation and throwing of each exception requires the stack, at the point of the throw, to be captured and saved in the exception. Unfortunately, without analyzing when, where, and how such exceptions are used, it may be difficult to identify or quantify any loss of performance.
Accordingly, a need exists for a system and method that can analyze exceptions generated during runtime to determine problems, isolate errors, and improve performance.